5.2 . Notas técnicas sobre las herramientas
En esta sección se explican algunos de los razonamientos y detalles técnicos detrás del sistema de construcción . No es esencial para comprender de inmediato todo lo que en esta sección se incluye. La mayor parte de esta información tendrá sentido cuando hayas hecho una construcción real. Esta sección puede ser referida en cualquier momento durante el proceso .
El principal objetivo del Capítulo 5 es producir un área temporal que contiene un conocido buen conjunto de herramientas que se pueden aislar del sistema host. Mediante el uso de chroot, los comandos en los capítulos restantes estarán contenidos dentro de ese ambiente , asegurando una construcción limpia y sin problemas del sistema LFS . El proceso de construcción ha sido diseñado para reducir al mínimo los riesgos para los nuevos lectores y proporcionar el mayor valor educativo al mismo Espacio requerido en disco.
![[Note]](../images/note.png)
Nota
Antes de continuar , tenga en cuenta el nombre de la plataforma de trabajo , a menudo referido como el "triple-objetivo". Una forma sencilla de determinar el nombre del triple objetivo es ejecutar el script config.guess que viene con la fuente de muchos paquetes. Descomprime las fuentes de Binutils, ejecuta el script ./config.guess y anota el resultado . Por ejemplo , para un procesador moderno Intel de 32 bits de la salida será probablemente i686- pc- linux- gnu .
También ten en cuenta el nombre del enlazador dinámico de tu plataforma , a menudo referido como el cargador dinámico (que no debe confundirse con el enlazador estándar ld que es parte de Binutils ) . El enlazador dinámico suministrado por Glibc encuentra y carga las librerías compartidas necesarias para un programa, prepara el programa para correr, y luego lo ejecuta. El nombre del enlazador dinámico para una máquina de 32 bits de Intel será ld- linux.so.2 . Una manera segura de determinar el nombre del enlazador dinámico es inspeccionar un binario cualquiera de tu sistema anfitrión ejecutando: readelf - l "nombre del binario" | grep intérprete y anotar la salida . La referencia autorizada que cubre todas las plataformas está en el fichero fichero shlib -versions en la raíz del árbol de las fuentes de Glibc .
Algunas claves técnicas sobre cómo funciona el método de construcción delCapítulo 5
-
Ajustar un poco el nombre de la plataforma de trabajo , cambiando el campo "vendor" del triple-objetivo por medio de la variable LFS_TGT , asegura que la primera compilación de Binutils y GCC produce un compatible linkador y compilador. En lugar de producir binarios para otra arquitectura , el enlazador y compilador producirán binarios compatibles con el hardware actual.
-
Las bibliotecas temporales son compiladas por un compilador cruzado. Debido a que un compilador cruzado por su naturaleza, no puede confiar en nada que provenga de su sistema host , este método elimina la posible contaminación del sistema objetivo por la disminución de las posibilidades de las cabeceras o bibliotecas desde el host anfitrión de incorporarse a las nuevas herramientas. Una compilación cruzada también permite la posibilidad de la construcción de bibliotecas tanto de 32 bits como de 64 bits en hardware de 64 bits.
-
Una cuidada manipulación de la fuente de GCC le dice al compilador cuál es el enlazador dinámico a usar .
Se instala primero Binutils debido a que "configure" tanto en GCC y Glibc realizan varias pruebas de función en el ensamblador y enlazador para determinar qué características del software se deben activar o desactivar . Esto es más importante de lo que uno podría pensar . Un GCC o Glibc incorrectamente configurado puede provocar unas herramientas sutilmente rotas , donde el impacto de dicha rotura puede no notarse hasta casi el final de la construcción de una distribución completa . Un fallo de banco de pruebas normalmente resaltará dicho error antes de perder demasiado Espacio requerido en disco adicional.
Binutils instala su ensamblador y enlazador en dos ubicaciones , /tools/bin y /tools/$LFS_TGT/bin. Las herramientas de una ubicación son enlaces duros a la otra . Un aspecto importante del enlazador es su orden de búsqueda de librerías . La información detallada se puede obtener de ld pasándole la opción - verbose . Por ejemplo , un ld - verbose | grep SEARCH mostrará las rutas de búsqueda actuales y su orden. Muestra qué archivos están enlazados por ld compilando un programa simulado y pasándole la opción - verbose . Por ejemplo , gcc dummy.c -Wl , - verbose 2 > & 1 | grep succeeded, mostrarán todos los archivos abiertos con éxito durante el enlace.
El siguiente paquete instalado es GCC. Un ejemplo de lo que puede verse en su fase configure :
checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld
Esto es importante por las razones mencionadas anteriormente. También demuestra que el guión configure de GCC no explora los directorios del PATH para encontrar las herramientas a utilizar . Sin embargo, durante la operación real del propio gcc , no se utilizan necesariamente las mismas rutas de búsqueda . Para averiguar qué enlazador estándar utilizará gcc , ejecuta: gcc -print-prog-name=ld .
La información detallada se puede obtener a partir de gcc pasándole la opción de línea de comandos- v mientras compilas un programa simulado . Por ejemplo , gcc -v dummy.c mostrará información detallada sobre el preprocesador , compilación y fases de montaje , incluyendo las rutas de búsqueda de gcc y su orden .
Lo siguiente instalado desinfecta las cabeceras API de Linux . Esto permite a la biblioteca estándar de C ( glibc ) interactuar con las características que el núcleo de Linux va a dar.
A continuación se instala Glibc. Las consideraciones más importantes para la construcción de Glibc son el compilador , las herramientas de binarios y las cabeceras del núcleo . Normalmente el compilador no es problema, pues Glibc siempre utilizará el compilador en relación con el parámetro que el host anfitrión pasó a su script de configuración , por ejemplo, en nuestro caso, i686 - lfs -linux- gnu -gcc . Las herramientas de binarios y las cabeceras del núcleo pueden ser un poco más complicado. Por lo tanto , no arriesgues y utiliza las opciones disponibles de configure para forzar las opciones correctas. Después de ejecutar configure puedes revisar el contenido del archivo config.make en el directorio glibc- build para ver todos los detalles importantes . Observa el uso de CC = " i686 - lfs -gnu -gcc " para controlar que se utilizan herramientas de binarios y el uso de la opciones-nostdinc y isystem flags para controlar el compilador de la ruta de búsqueda . Estos detalles ayudan a resaltar un aspecto importante del paquete Glibc: es muy autosuficiente en cuanto a su maquinaria de construcción y generalmente no se basa en defecto de las herramientas .
Durante la segunda fase de Binutils , somos capaces de utilizar la opción - with-lib-path de configure para controlar la ruta de búsqueda de librerías de ld .
Para la segunda fase de GCC , sus fuentes también deben ser modificados para decirle GCC que utilice el nuevo enlazador dinámico . De no hacerlo, dará lugar a los programas de GCC tomen por nombre el del enlazador dinámico del directorio /lib del sistema huésped,incrustándolo en ellos, lo que arruinaría nuestro objetivo de librarnos del anfitrión. Desde este punto en adelante, la cadena de herramientas principal será autónoma y auto-organizada . El resto de los paquetes del Capítulo 5 se construirán todos contra la nueva Glibc en /tools.
Al entrar en el entorno chroot en el Capítulo 6, el primer gran paquete a instalar es Glibc , debido a su naturaleza autosuficiente antes mencionado. Una vez que esta Glibc se instale dentro de /usr , haremos un rápido cambio de las toolchain por defecto , y luego procederemos a la construcción real del sistema LFS .